feat(gui): drag the divider to resize the two panes - #40

The panes were a fixed 3:2, which is a guess about somebody else's screen. On a narrow window the right pane's tab strip runs out of room and clips the last tab - "Diagnostics (2)" was the one that prompted this - and there was nothing to do about it: the space between the lists was a gap, not a handle.

Now it is a handle

Six pixels, full height, the toolbars' muted line at rest and the panel border's burgundy while held, so a drag in progress is visible rather than inferred.

Clamped in both places

The ratio is held to 0.15..0.85 in the live drag and in the settings parser. A pane dragged to zero takes the divider with it, and then neither pane can be recovered - so an out-of-range value in settings.ini reads as the default rather than as a preference somebody chose. That is the policy drag_scroll_speed already applies, reused rather than reinvented.

It is written to settings.ini on release, not on every pointer move: the drag emits a message per frame and the settings are a file.

Nothing new was needed to carry it

app.cursor and app.window were already tracked, mouse_area was already imported, and PointerAt was already in is_ambient - which matters, because resizing the furniture must not disarm a two-click confirmation armed on a row. SplitGrab joins it for the same reason.

Tested through the real message loop

• the pointer alone does not resize (the divider is a handle, not a hover target)
• a grab makes it follow
• both clamps hold when dragged past either edge
• release stops the drag and hands the value to the preferences
• a move after release is inert again

Plus a settings round-trip that refuses 0, 1, 0.05, 0.99, -1, abc and the empty string.

254 GUI tests, workspace green, clippy clean on the pinned 1.94.1.